Speed up loading file statuses in Git commit dialog by batching events and skipping events for up-to-date files by OndroMih · Pull Request #9324 · apache/netbeans

OndroMih · 2026-04-04T16:10:41Z

Skip firing events for up-to-date

Skip firing events for up-to-date files that are not
yet in the cache, since UPTODATE is the default for managed files.
This drastically reduces the time spent in the refreshStatusesBatch method on big repositories executed when Commit dialog opens. For example, on the Netbeans repository, from around 8 seconds to 20ms.

Batch status change notifications

Batch status change notifications to avoid per-file event overhead.

Replace per-file PROP_FILE_STATUS_CHANGED firing in refreshStatusesBatch
with a single PROP_FILES_STATUS_CHANGED batch event, eliminating 100k
redundant propertyChange/schedule/SwingUtilities.invokeLater calls on
first load. This improves performance a bit because it eliminates many method calls.
However, in the end, the number of files changed is the same so the event handler
still needs to process all of them.

Move status updates to a background thread

File status update requires I/O operation to refresh files metadata from FS. This is very slow when many files need to be updated. Moving them to a background thread offloads this slow operation from the main thread.
Updates can run asynchrnously without blocking the main thread that fires the status events, they just update UI hints, they have no impact no behavior.
For the whole Netbeans repository, this shortens the time it takes to complete the firePropertyChange event from 6 seconds to 1 second.

Complements #9304, which speeds up the process even more, in a different area.

Click to collapse/expand PR instructions

PR approval and merge checklist:

Was this PR correctly labeled, did the right tests run? When did they run?
Is this PR squashed?
Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

mbien

this looks good to me. Thanks a lot for the improvements.

left some comments inline but its nothing important

mbien · 2026-04-05T06:36:26Z

ide/git/src/org/netbeans/modules/git/FileStatusCache.java

-        for (ChangedEvent event : events) {
-            fireFileStatusChanged(event);
+        if (!events.isEmpty()) {
+            listenerSupport.firePropertyChange(PROP_FILES_STATUS_CHANGED, null, events);


good catch. aggregating events can certainly reduce overhead under load. Reminds me a little on #8955 where I saw 1.5mil event handler invocations when a large project group opened.

Actually, the overhead reduction is almost negligible. I was tempted to remove this but then I found out one more way to optimize this, by running the property change listeners asynchronously in background thread.

Each single file status update is an I/O operation and thus slow. Running the updates in background moves this off the main thread. Running everything in batch allows offloading everything to a single background thread instead of updating each file in separate thread, which might be slower because of synchronization between threads.

Therefore I kept the property change event for all of the files and changed the 2 listeners to run in background, updating all the files with a single background thread.

mbien · 2026-04-05T07:01:56Z

ide/git/src/org/netbeans/modules/git/GitVCS.java

            fireStatusChanged(changedEvent.getFile());
+        } else if (event.getPropertyName().equals(FileStatusCache.PROP_FILES_STATUS_CHANGED)) {
+            List<FileStatusCache.ChangedEvent> changedEvents = (List<FileStatusCache.ChangedEvent>) event.getNewValue();
+            Set<File> files = new HashSet<>(changedEvents.size());


this is super nitpicky. but the constructor arg isn't for the element count, it is to size the internal table - which sometimes leads to initial sizes which are too small.

if you want you can bump the module to javac.release=21 (see project.properties) and then use the HashSet.newHashSet(numElements) factory which does some math before setting the size of the internal table.

feel free to update the commit and force push in place.

Updated as suggested

mbien · 2026-04-05T07:37:13Z

ide/git/src/org/netbeans/modules/git/ui/diff/MultiDiffPanelController.java

+            for (FileStatusCache.ChangedEvent changedEvent : changedEvents) {
+                if (revisionLeft == Revision.HEAD // remove when we're able to refresh single file changes for Local vs. any revision
+                        && revisionRight == Revision.LOCAL && affectsView(changedEvent)) {


could the revisionLeft/Right check be moved before the loop?

Updated as suggested

mbien · 2026-04-07T11:36:36Z

@OndroMih for some reason I see an extra commit in this PR branch.

git pull --rebase --autostash git@github.com:apache/netbeans master
should hopefully resolve it.

OndroMih · 2026-04-07T11:54:45Z

@mbien , I implemented the changes you requested, please review again.

I added one more optimization - property change listeners run asynchronously - they both do a slow I/O operation for each file and running them asynchronously unblocks the main thread. This doesn't have impact on functionality because the final stage of updating the statuses was already asynchronous and it only updates the icons of files to reflect they status.

Here's a sceenshot from profile before the change - the firePropertyChange event took 6 seconds:

After these changes, when I forced update also on noupdate files, this decreased to 1 second:

When I put back skipping update on noupdate files, the firePropertyChange method is rarely called at all. And if it is, then only with a few files that are not marked with noupdate.

OndroMih · 2026-04-07T12:18:13Z

@mbien

@OndroMih for some reason I see an extra commit in this PR branch.

Thanks, I did it and it seems it helped.

mbien · 2026-04-07T12:46:33Z

ide/versioning.core/src/org/netbeans/modules/versioning/core/VersioningAnnotationProvider.java

+        final RequestProcessor.Task refreshAnnotationsTask = rp.create(() -> {
+
+            if (files == null) {
+                LOG.log(Level.FINE, "refreshing all annotations"); //NOI18N
+                refreshAllAnnotationsTask.schedule(2000);
+                return;
            }


first if check could be before the task in the refreshAnnotations() method.

Changed. Thanks.

## Skip firing events for up-to-date Skip firing events for up-to-date files that are not yet in the cache, since UPTODATE is the default for managed files. This drastically reduces the time spent in the refreshStatusesBatch method on big repositories executed when Commit dialog opens. For example, on the Netbeans repository, from around 8 seconds to 20ms. ## Batch status change notifications Batch status change notifications to avoid per-file event overhead. Replace per-file PROP_FILE_STATUS_CHANGED firing in refreshStatusesBatch with a single PROP_FILES_STATUS_CHANGED batch event, eliminating 100k redundant propertyChange/schedule/SwingUtilities.invokeLater calls on first load. This improves performance a bit because it eliminates many method calls. However, in the end, the number of files changed is the same so the event handler still needs to process all of them. ## Move status updates to a background thread File status update requires I/O operation to refresh files metadata from FS. This is very slow when many files need to be updated. Moving them to a background thread offloads this slow operation from the main thread. Updates can run asynchronously without blocking the main thread that fires the status events, they just update UI hints, they have no impact no behavior. For the whole Netbeans repository, this shortens the time it takes to complete the firePropertyChange event from 6 seconds to 1 second.

OndroMih mentioned this pull request Apr 4, 2026

Optimization of Git commit dialog finding changed files #9304

Open

4 tasks

mbien added git [ci] enable versioning job ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) labels Apr 4, 2026

apache locked and limited conversation to collaborators Apr 4, 2026

apache unlocked this conversation Apr 4, 2026

mbien added the performance label Apr 4, 2026

mbien approved these changes Apr 5, 2026

View reviewed changes

OndroMih force-pushed the ondromih-git-commit-dlg-optimization-skip-no-update branch from 94bdb4a to e48d9d6 Compare April 7, 2026 11:24

OndroMih force-pushed the ondromih-git-commit-dlg-optimization-skip-no-update branch from e48d9d6 to 2f76482 Compare April 7, 2026 12:17

mbien reviewed Apr 7, 2026

View reviewed changes

mbien self-requested a review April 7, 2026 12:46

OndroMih force-pushed the ondromih-git-commit-dlg-optimization-skip-no-update branch from 2f76482 to 642c71b Compare April 7, 2026 13:17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Speed up loading file statuses in Git commit dialog by batching events and skipping events for up-to-date files#9324

Speed up loading file statuses in Git commit dialog by batching events and skipping events for up-to-date files#9324
OndroMih wants to merge 1 commit intoapache:masterfrom
OndroMih:ondromih-git-commit-dlg-optimization-skip-no-update

OndroMih commented Apr 4, 2026 •

edited

Loading

Uh oh!

mbien left a comment

Uh oh!

mbien Apr 5, 2026

Uh oh!

OndroMih Apr 7, 2026

Uh oh!

mbien Apr 5, 2026

Uh oh!

OndroMih Apr 7, 2026

Uh oh!

mbien Apr 5, 2026

Uh oh!

OndroMih Apr 7, 2026

Uh oh!

mbien commented Apr 7, 2026

Uh oh!

OndroMih commented Apr 7, 2026

Uh oh!

OndroMih commented Apr 7, 2026

Uh oh!

mbien Apr 7, 2026

Uh oh!

OndroMih Apr 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

OndroMih commented Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Skip firing events for up-to-date

Batch status change notifications

Move status updates to a background thread

PR approval and merge checklist:

Uh oh!

mbien left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mbien commented Apr 7, 2026

Uh oh!

OndroMih commented Apr 7, 2026

Uh oh!

OndroMih commented Apr 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

OndroMih commented Apr 4, 2026 •

edited

Loading